<!-- saved from url=(0022)http://internet.e-mail -->
<html>

<head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta name="Author" content="Eclipse Project PMC">
<title>Why Eclipse 3</title>
<link rel="stylesheet" href="../../default_style.css" type="text/css">
</head>

<body>

<h1>Why Eclipse &quot;3.0&quot;?</h1>
<p>We're changing the designation of the next Eclipse release to 3.0 from 2.2. 
  This note explain why, and what it means to you.</p>
<blockquote> 
  <p><a href="#why3">Why is the next release of Eclipse called 3.0 rather than 
    2.2?</a><br>
    <a href="#API">Does this mean that Eclipse APIs will be changing in incompatible 
    ways?</a> <br>
    <a href="#plugins">Does this mean that plug-ins based on Eclipse 2.0 and 2.1 
    will not work in 3.0?</a> <br>
    <a href="#much">Will a lot of the Eclipse APIs be changing?</a> <br>
    <a href="#whynow">Why break compatibility now?</a> <br>
    <a href="#which">Which APIs will changed for 3.0?</a> <br>
    <a href="#when">When will breaking API changes be made?</a> <br>
    <a href="#whodecides">How do we decide whether a breaking change goes in?</a> 
    <br>
    <a href="#forteams">What does this change mean for teams working on 3.0?</a> 
    <br>
    <a href="#forcusts">What does this change mean for customers waiting for 3.0?</a> 
    <br>
    <a href="#forproducts">What does this mean for products shipping on 2.1?</a> 
  </p>
</blockquote>
<h3><a name="why3"></a>Why is the next release of Eclipse called 3.0 rather than 
  2.2?</h3>
<p>For the next Eclipse release we are planning both consolidation and major new 
  functionality. Some of the changes that we are considering would require us 
  to break compatibility with existing plug-ins. Incrementing the minor version 
  number from &quot;2.1&quot; to &quot;2.2&quot; suggested that all existing 2.* 
  plug-ins would run on the new release without change. Changing the major version 
  number from &quot;2&quot; to &quot;3&quot; suggests that existing 2.* plug-ins 
  do not work with the new release, and would need to be ported to 3.0. This gives 
  the development team more maneuvering room and more accurately sets expectations.</p>
<h3><a name="API"></a>Does this mean that Eclipse APIs will be changing in incompatible 
  ways?</h3>
<p>Yes. Some of the Eclipse APIs will likely change in ways that will require
rewriting portions of existing plug-ins written to the 2.* APIs. Most of the
Eclipse APIs will remain the same.</p>
<h3><a name="plugins"></a>Does this mean that plug-ins based on Eclipse 2.0 and 
  2.1 will not work in 3.0?</h3>
<p>Yes. The changes to the Eclipse APIs in 3.0 will mean that existing 2.1 (and
2.0) plug-ins will not work with Eclipse 3.0. Developers of 2.1 plug-ins will
need to port them to 3.0, and ship new versions of their plug-ins.</p>
<h3><a name="much"></a>Will a lot of the Eclipse APIs be changing?</h3>
<p>No. Most of the Eclipse APIs will be the same in 3.0 as in 2.1. In general, 
  we are satisfied with the state of all Eclipse APIs in 2.1 and have no inclination 
  (or time) to start over. We would only break APIs in 3.0 when have a compelling 
  case for doing so. And when we find we need to break APIs, we would do it in 
  a controlled way that minimizes the effort required to port an existing plug-in 
  to the 3.0 APIs. We are not interested in breaking APIs willy-nilly.</p>
<h3><a name="whynow"></a>Why break compatibility now?</h3>
<p>Maintaining compatibility incurs a cost by stifling radical improvements and 
  making it hard to outgrow past mistakes. Breaking compatibility incurs a cost 
  because it generally makes life more difficult for plug-in tool authors and 
  customers alike. Some of the improvements under consideration are difficult 
  to pursue while maintaining compatibility. For instance, changing Eclipse so 
  that it can be used as a rich-client platform will almost certainly require 
  breaking API changes to decouple the workbench UI from workspace and resources 
  and parcel up workspace-free functionality into new plug-ins. The freedom to 
  break compatibility gives us additional freedom to innovate and make the next 
  Eclipse significantly better than it could have been had we tried to maintain 
  compatibility.</p>
<h3><a name="which"></a>Which APIs will changed for 3.0?</h3>
<p>We don't know which APIs will change at this point. We plan to provide a comprehensive 
  <i>Eclipse 3.0 Porting Guide</i> that covers all areas where we've made breaking 
  API changes, and describes how to port existing 2.1 plug-ins to 3.0. Up-to-date 
  drafts of the <i>Eclipse 3.0 Porting Guide</i> will be included with each milestone 
  build so that it's possible to climb aboard the 3.0 release wagon at the early 
  stages, or to estimate the amount of effort that will be involved in eventually 
  porting existing plug-ins to 3.0.</p>
<h3><a name="when"></a>When will breaking API changes be made?</h3>
<p>Since breaking API changes also destabilize the development of 3.0, we plan 
  to make all breaking API changes early in the cycle. We plan to make the breaking 
  API changes in batches so that for our internal development we do not get into 
  a constant API catch-up mode. By the end of calendar year 2003 (milestone M5), 
  all breaking API changes will be in place and tested. This will allow the remainder 
  of the 3.0 release cycle to proceed without further disruption, and allow existing 
  plug-ins to be ported to the new 3.0 APIs in parallel.</p>
<h3><a name="whodecides"></a>How do we decide whether a breaking change goes in?</h3>
All breaking API changes will be reviewed by the Eclipse development team leads 
and the Eclipse Project PMC to ensure that there is a sound case for breaking 
compatibility on certain APIs, and that the breakage is minimized. The appropriate 
section for the Eclipse 3.0 Porting Guide will show how to rewrite affected code 
to work with the new APIs. 
<h3><a name="forteams"></a>What does this change mean for teams working on 3.0?</h3>
This is a golden opportunity to address some big problems. Go for it! 
<h3><a name="forcusts"></a>What does this change mean for customers waiting for 
  3.0?</h3>
<p>Sit tight and don't worry. Wherever we end up, we'll show you how to get
there from here.</p>
<h3><a name="forproducts"></a>What does this mean for products shipping on 2.1?</h3>
<p>Nothing has changed. Eclipse 2.1 is the most up-to-date stable base for Eclipse 
  plug-ins and products. We will continue to fix significant defects in this code 
  base, and issue fixes as patches and as periodic 2.1.* maintenance releases. 
</p>
</body>

</html>
